The movement of a terminal in a mobile communication networks requires location updates in order to stay reachable for the terminal. The current location of a terminal in the network is stored in a mobility management entity and every time the location is changed, the mobile terminal sends a location update message to this mobility management entity. Downlink packets destined to the terminal can then be delivered to the current location.
For example in an IP-based network, Mobile IP is an exemplary protocol supporting mobility. The mobility management entity in this protocol is referred to as the Home Agent (HA) and when the mobile terminal moves and attaches to a new subnet it configures a new IP address and registers this IP address as Care-of Address (CoA) with the HA. IETF RFC 3775, “Mobility Support in IPv6” and IETF RFC 3344, “IP Mobility Support for IPv4” (available at http://www.ietf.org) describe the protocol mechanisms for IP mobility support in IP-based networks for IPv6 and IPv4 networks, respectively, and are both incorporated herein by reference.
Concerning mobility management in cellular networks (e.g. UMTS) the terminals perform so-called location updates. A cellular network typically has a cellular structure where individual or plural radio cells may form a so-called location area. The network provides the terminals with information about the cell and location area they are currently located in. Typically, this is achieved by broadcasting system information in the radio cells from which the terminals may derive the respective information.
The terminals may compare the stored location area with the location area received from the network and whenever a terminal detects a change of the location area it performs a location update procedure.
In the exemplary case of UMTS the terminal sends a so-called Routing Area Update Request message, including its temporary identity and old routing area identity to the Serving GPRS Support Node (SGSN) and the Serving Radio Network Controller (SRNC) adds the routing area identity of the current area to the message. In case of an inter-SGSN Routing Area Update in idle mode, the new SGSN will request context information from the old SGSN (for details, please see 3GPP TS 23.060: “General Packet Radio Service (GPRS); Stage 2 (Release 7)” version 7.0.0, section is 6.9.2, incorporated herein by reference).
In the evolved 3GPP system architecture (see 3GPP TR 23.882: “3GPP System Architecture Evolution Report on Technical Options and Conclusions”, version 1.0.0, available at http://www.3gpp.org and incorporated herein by reference) similar mechanisms are suggested for use to track a mobile terminal in evolved UMTS systems. Here the mobile terminal will send a so-called Tracking Area Registration message to the MME/UPE when the tracking area has changed as exemplarily shown in FIG. 1.
In the architecture described in 3GPP TR 23.882, the Mobility Management Entity (MME) manages and stores UE context (for idle state: UE/user identities, UE mobility state, user security parameters) and generates temporary identities and allocates them to UEs. It checks the authorization whether the UE may camp on the TA or on the PLMN. It also authenticates the user.
The User Plane Entity (UPE) terminates for idle state UEs the downlink data path and triggers/initiates paging when downlink data arrive for the UE. Moreover, the UPE manages and stores UE contexts, e.g. parameters of the IP bearer service or network internal routing information. The UPE may further also perform replication of the user traffic in case of interception.
As shown in FIG. 1, MME and UPE define functional entities in the network that are collocated in a network element. The MME/UPE 102, 103 are connected to a 3GPP radio access system that serves the UEs via base stations denoted enhanced Node Bs (or eNode B) of the evolved UMTS system. Further, the MME/UPE 102, 103 are connected to an Inter AS Anchor 101 providing connectivity to other networks. Further, it is assumed in FIG. 1 for exemplary purposes that the service area covered by the 3GPP Radio AS is segmented in different tracking areas (TAs) 104, 105, 106 that may also be denoted as location areas.
Every time a UE changes from one TA to another TA, it performs a tracking area registration procedure (or update) with its serving MME as indicated in FIG. 1.
E.g. when UEs 107, 108, 109 move to tracking area 104 (and assuming that the serving MME/UPE changes), each of the UEs 107, 108, 109 will initiate a tracking area registration procedure with the new serving MME/UPE 102. Since the MME/UPE has been changed, also an update of the User Plane Route between Inter AS Anchor 101 and the new MME/UPE 102 is performed. UEs 107, 108, 109 move together to tracking area 105, where they again individually perform a tracking area registration procedure with the serving MME/UPE 102. Further, upon movement of UEs 107, 108, 109 to tracking area 106, UEs 107, 108, 109 again perform a tracking area registration procedure with the new serving MME/UPE 103 which will also initiate a User Plane Route update for each of UEs 107, 108, 109 with Inter AS Anchor 101, since the serving UPE has been changed.
When several mobile terminals move together (e.g., terminals of travelers in a train), every single terminal sends a Tracking Area Registration and receives a Tracking Area Registration Confirmation every time the Tracking Area is changed and therefore a flooding of signaling messages is caused.